[SYCL][CMAKE] Fix _FORTIFY_SOURCE=3 #19268
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The problem here is that the macro is actually handled by glibc and value `3` isn't supported with older compiler/glibc combinations, causing warnings about the macro redefinition. We still have to support older compilers/glibc and therefore as a temporary solution, reverting `_FORTIFY_SOURCE` back to `2` to avoid build issues with `-Werror`.
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
KornevNikita
approved these changes
Jul 2, 2025
sarnex
reviewed
Jul 2, 2025
| @@ -167,18 +167,18 @@ macro(append_common_extra_security_flags) | |||
| if(LLVM_ON_UNIX) | |||
| # Fortify Source (strongly recommended): | |||
| if(CMAKE_BUILD_TYPE STREQUAL "Debug") | |||
| message(WARNING "-D_FORTIFY_SOURCE=3 can only be used with optimization.") | |||
| message(WARNING "-D_FORTIFY_SOURCE=3 is not supported.") | |||
| message(WARNING "-D_FORTIFY_SOURCE=2 can only be used with optimization.") | |||
There was a problem hiding this comment.
Is there a way we can detect what compiler we can use 3 on and use that and use 2 otherwise?
There was a problem hiding this comment.
Is there a way we can detect what compiler we can use
3on and use that and use2otherwise?
Theoretically, but it is not clear which exact versions are "good" and which ones are "bad". It seems like gcc 12 is the first "good" (link), but I'm not sure about clang
There was a problem hiding this comment.
The doc says There has been compiler support for this builtin in [Clang](https://clang.llvm.org/) for some time so maybe we can just ignore it/check for some really old version?
If 3 has some benefit IMO we should try to add a check to see if we can use it if it's not too complicated
There was a problem hiding this comment.
075da8c introduces the check. I also had to uplift _FORTIFY_SOURCE in the Unified Runtime to avoid macro redefinition. We set it globally, but UR also sets it locally, because it is intended to buildable standalone.
I tried to uplift _FORTIFY_SOURCE in UR in #19236 and this is how I detected the issue with "bad" gcc, so we will see now if the suggested check works.
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
temporarily deployed
to
WindowsCILock
GitHub Actions
Inactive
AlexeySachkov
changed the title
|
@intel/unified-runtime-reviewers, could you please take a look? |
kbenzie
approved these changes
Jul 8, 2025
sarnex
approved these changes
Jul 9, 2025
AlexeySachkov
added a commit
that referenced
this pull request
Jul 11, 2025
The problem here is that the macro is actually handled by glibc and value `3` isn't supported with older compiler/glibc combinations, causing warnings about the macro redefinition. We still have to support older compilers/glibc and therefore two changes were made: - UR skips setting their own `_FORTIFY_SOURCE` in favor of a global one if it is built as part of LLVM (i.e. not standalone) - Before setting `_FORTIFY_SOURCE` globally we check the compiler and fallback to value `2` for older gcc
AlexeySachkov
added a commit
that referenced
this pull request
Jul 16, 2025
This PR contains several cherry-picks and some unique changes which have not been applied to the `sycl` branch yet. The intent of this PR is to enable as much (quickly) possible hardening flags to be in better compliance with our SDL requirements. The main thing this PR is after are things like immediate bindings, fortify source, stack protection and `relro`. The thing that this PR is **not** after are extra warning flags - some of them we can't apply globally because LLVM itself isn't warning free, some of them we can't apply even locally to SYCL RT because we haven't fixed corresponding warnings yet. Patches which were cherry-picked from the `sycl` branch: - [SYCL] Fix AddSecurityFlags having no side effects (#17690) - Patch-By: Alexey Sachkov <[email protected]> - [SYCL] Refresh hardening flags applied to the project (#18398) - Patch-By: Nikita Kornev <[email protected]> - [SYCL][CMAKE] Refactor -fPIE handling (#19235) - Patch-By: Alexey Sachkov <[email protected]> - [SYCL][CMAKE] Drop nodlopen from hardening flags (#19357) - Patch-By: Alexey Sachkov <[email protected]> - [SYCL][CMAKE] Fix _FORTIFY_SOURCE=3 (#19268) - Patch-By: Alexey Sachkov <[email protected]> - [SYCL][CMake] Properly enable -pie hardening flag (#19447) - Patch-By: Alexey Sachkov <[email protected]> Additional changes which have **not** been applied to the `sycl` branch: - Adjusted `configure.py` to the new way of `-fPIE` handling - Dropped `/sdl` flag because LLVM isn't warning-free - it will be applied locally to SYCL RT in a separate PR against the `sycl` branch for future releases - Dropped `/analyze` flag because SYCL RT isn't warning-free - it will be applied locally to SYCL RT in a separate PR against the `sycl` branch for future releases
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The problem here is that the macro is actually handled by glibc and value
3isn't supported with older compiler/glibc combinations, causing warnings about the macro redefinition.We still have to support older compilers/glibc and therefore two changes were made:
_FORTIFY_SOURCEin favor of a global one if it is built as part of LLVM (i.e. not standalone)_FORTIFY_SOURCEglobally we check the compiler and fallback to value2for older gcc